Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1990/90-07

Text File | 1995-12-31 | 33KB | 1,078 lines

Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: test
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 1
Date: 1 Jul 90 20:10:02 GMT
Phone: [phone]

test of list channel gateway.










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: Archive Information
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 100
Date: 2 Jul 90 21:30:33 GMT
Phone: [phone]

I've decided to a bit of refinement of the archive directory since
it looks as though the types of submissions will be varied enough to
warrant a better organization scheme.  The following is in
/mac/think-c/README.archive:

/*****************************************************************************/

The archive is organized (currently) as follow:

classes
    This contains Think C source code for classes for TC 4.0+.

compiler
    This contains files useful for enhancing the Think C
    compiler.  This includes extra include files (like
    prototypes) and upgrades from Symantec.

demos
    This contains demo programs.  Since some people are not
    interested in such items, I've decided to separate them all
    out into one subdirectory.

examples
    This contains fragments of code that serve as examples, but
    that are not classes.

programs
    This contains full source to programs (i.e., compile them
    and they become applications).

system
    This contains full source to MacOS system enhancement code
    resources, like CDEFS, MDEFS, etc.

/*****************************************************************************/

If anyone has any suggestions for better names and/or organizational
tips, please let me know.

Here is the current directory of the archive (it's small now, so I
can still do this :-):

/mac/think-c:
README.archive
README.submit
classes
compiler
demos
examples
programs
system

classes:
DynamicArrays.hqx
DynamicArrays.intro
cdialog.hqx
cdialog.intro
various.hqx
various.intro

compiler:
protos-imv.h
protos-imv.intro

demos:
Prepare-Demo-1-1.hqx
Prepare-Demo-1-2.hqx
Prepare-Demo.intro

examples:
atm-examples.hqx
atm-examples.intro
pap-routines-c.txt
pap-routines-doc.txt
pap-routines-h.txt

programs:
GenAPP.hqx
GenAPP.intro
bison.hqx
bison.intro
flex.hqx
flex.intro

system:
popupCDEF.hqx
popupCDEF.intro

As you can see, I am trying to separate out the headers of the
submissions so that they are available for quick retrieval prior to
full retrieval of the archive file.

I have received enough requests for a mail archive server that I am
currently pursuing this.  More when I have found or written one...

That's all for now.  There are now about 150 members on this list
with at least 4 exploders.  You shouldn't feel at all shy about
actually using this list if the need arises.

Mark










Path: ucivax!gateway
From: bootsie![e-mail] (Eric Olson)
Subject: Curious TCL bug
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 41
Date: 3 Jul 90 02:47:19 GMT

OK, TCL Hackers!  Here it is: the hardest bug you'll ever want to find!

Many, if not all, programs compiled using the Think Class Library exhibit
a very strange behavior:  every once in a while, the program will decide
that the mouse button has been released, even though it has not.  This
behavior presents itself during menu pulls and CMousetask subclasses.
It may also appear in scroll bar thumb drags.

An example is drawing a very long squiggly line in Art Class:  eventually,
the line will end, even though the mouse button was not released.

It's worth noting that both menu pulls and MouseTasks use the toolbox
function StillDown() to determine if the mouse button has been released.

Does anyone know the root of this evil?

Some possibilities include:  some event queue filling up (events are
not processed inside the loop of a MouseTask); the ADB bus getting
confused (can someone report as to whether this behavior ever appears
on a (non-ADB) Mac+?); some intentional action on the part of the system
(that I've never heard of?).

If you can run Art Class and it never produces this behavior, please
let me know your system configuration in as much detail as possible.
If your system exhibits this behavior to the extreme, please do likewise.

Hopefully, we can track this thing down!  It's really starting to annoy me!

Regards,

Eric


--
Please note!  [e-mail] will not work!  Use an address below:

Eric K. Olson                 Internet:   [e-mail]
Lexington Software Design     Usenet:     harvard!endor!olson
72A Lowell St.                Applelink:  [e-mail]@dasnet#
Lexington, MA  02173          Compuserve: >INTERNET:[e-mail]
[phone]                Bitnet:     OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail] (Eric Yiskis)
Subject: Re:  Curious TCL bug
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 3 Jul 90 04:57:34 GMT


>>Many, if not all, programs compiled using the Think Class Library exhibit
>>a very strange behavior:  every once in a while, the program will decide
>>that the mouse button has been released, even though it has not.  This
>>behavior presents itself during menu pulls and CMousetask subclasses.
>>It may also appear in scroll bar thumb drags.


>>Does anyone know the root of this evil?

I too have had this problem, but I attributed it to my mouse ( in that
perhaps the button needs a certain amount of presure even though it is
clicked down.)  So is it software or faulty mouse buttons?  Does it only
happen in Think-C applications or does it happen in the finder too?  I'll
try to observe it more closely...

- Eric Yiskis ([e-mail])











Path: ucivax!gateway
From: [e-mail] (Gerhard Mehldau)
Subject: Re: TCL bug
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 3 Jul 90 05:52:47 GMT


  I tried mail, but it bounced...

  A while back there was a discussion on the net about
this bug appearing in THINK C 3.0, but *only* in the
debugger mode.  I also seem to recall that Rich Siegel
had an answer to this problem (or at least commented
on it), but, unfortunately, I don't recall what is was.

  As far as reproducing the bug with THINK C 4.0 goes,
I can't help you; I'm still running 3.0.2 (no TCL), but
I can reproduce it there under the debugger.

  Hope this helps.

- Gerhard











Path: ucivax!gateway
From: bootsie![e-mail] (Eric Olson)
Subject: That pesky TCL bug
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 30
Date: 3 Jul 90 08:43:35 GMT


Well folks, after a few more hours of hacking I have tentatively
decided that:

- The failure occurs somewhere inside StillDown().  Replacing StillDown()
with Button() (which is essentially the same, but a less reliable test
of whether the button has been depressed all along) inside a CMouseTask
eliminates the behavior.

- In the normal scheme of things, StillDown() will return TRUE until
a PostEvent() with a mouseUp event code is executed.  When the failure
occurs, PostEvent(mouseUp) is not called until the mouse button actually
_is_ released-- yet StillDown() has already returned FALSE!

- The problem is not related to the TCL growZoneFunc.

Sorry if my descriptions aren't too cogent right now.  It's late.
Any hints or guesses will be appreciated!

-Eric


--
Please note!  [e-mail] will not work!  Use an address below:

Eric K. Olson                 Internet:   [e-mail]
Lexington Software Design     Usenet:     harvard!endor!olson
72A Lowell St.                Applelink:  [e-mail]@dasnet#
Lexington, MA  02173          Compuserve: >INTERNET:[e-mail]
[phone]                Bitnet:     OLSON@HARVARD










Path: ucivax!gateway
From: bootsie![e-mail] (Eric Olson)
Subject: That TCL bug, part III
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 23
Date: 3 Jul 90 09:44:13 GMT


As Gerhard Mehldau has pointed out, this bug seems to only appear
when running the source debugger.  I can not get it to happen in
a compiled down application or if the source debugger is not running
in the project.

I'll call the people at Symantec and report back to y'all.

Thank goodness all our applications won't exhibit this behavior!

Regards,

-Eric


--
Please note!  [e-mail] will not work!  Use an address below:

Eric K. Olson                 Internet:   [e-mail]
Lexington Software Design     Usenet:     harvard!endor!olson
72A Lowell St.                Applelink:  [e-mail]@dasnet#
Lexington, MA  02173          Compuserve: >INTERNET:[e-mail]
[phone]                Bitnet:     OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail]
Subject: The cdev class and ModalDialog()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 38
Date: 3 Jul 90 18:03:07 GMT


    Please respond to the following via email to keep clutter from this mailing
list.  Thanks.

    I am writing a cdev using the THINK C cdev class.  It allows users to enter
config info for an INIT into editText fields & saves them in the resource
file.  If the user has entered invalid data and tries to close the cdev, I
want to display an error dialog & close with the "cdevGenErr".  I am trying to
use ModalDialog() on the error dialog window, but a nulDev message is
generated in the process, which causes a second call to Close() (a "sequence
of events" follows).  This hopelessly confuses the CP.  How do I (or even can
I) use ModalDialog() with the cdev class?

What I want to happen:
    1) user enters bad info & selects close (either closebox or other cdev)
    2) closeDev message sent to Message() -- sets status = 0 & calls custom
Close()
    3) Close() checks for bad data -- if good, saves; if bad, shows dialog &
calls ModalDialog() then DisposDialog()
    4) normal Close() -- deallocates the cdev
    5) CP greys out cdev area

What actually happens:
    1) same as above
    2) same
    3) Close() checks for bad data -- if good, saves; if bad, shows dialog &
calls ModalDialog()
    4) a nulDev now gets sent to Message() -- calls Idle() & then Close() (status
set to 0 in #2, so if-then still true)
    5) Close() checks data, shows dialog & calls ModalDialog() then
DisposDialog() -- no nulDev this time!
    6) normal Close() -- deallocates the cdev
    7) CP confused -- cdev deallocated, but call to ModalDialog() still "on the
books" -- waits for mouse click & crashes

Please respond to:
Guy ([e-mail])











Path: ucivax!gateway
From: bootsie![e-mail] (Eric Olson)
Subject: That Bug
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 16
Date: 3 Jul 90 20:12:59 GMT
MMDF-Warning: Unable to confirm address in preceding line at ICS.UCI.EDU


I called Symantec today to tell them everything I knew.  Rich Siegel is
on vacation right now, so I wasn't able to get his insight, but the
information that I've posted to this list has been duly logged and noted.

-Eric


--
Please note!  [e-mail] will not work!  Use an address below:

Eric K. Olson                 Internet:   [e-mail]
Lexington Software Design     Usenet:     harvard!endor!olson
72A Lowell St.                Applelink:  [e-mail]@dasnet#
Lexington, MA  02173          Compuserve: >INTERNET:[e-mail]
[phone]                Bitnet:     OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail] (Robert Wald)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 4 Jul 90 12:25:18 GMT

  I'm about to do some Mac programming after a few years absence, and
was either going to do it in TCL or MacApp. Last time I used MacApp was
in its beta release, so I was wondering if anyone has compared it to
the TCL library and can send me some info on how TCL compares with
MacApp 2.0 and the forthcoming 3.0. Which is easier to use, more complete.
Actually, I assume that MacApp is better, but how much good
functionality does TCL provide
?
Thanks.

TO respond directly, please send to [e-mail], not
to the address this came from. Thanks

-Rob











Path: ucivax!gateway
From: [e-mail] ("Jerry Gilliam (Server Drivers")
Subject: Think C qsort
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 5 Jul 90 17:00:00 GMT
MMDF-Warning: Parse error in original version of preceding line at ICS.UCI.EDU

I recently had occasion to use the qsort function packaged with
Think C 4.0, and it appears to be buggy.  The resulting data
was only partially sorted.  Large chunks of the data were sorted,
but there was still very gross disorder.  I tried writing a
simple bubble sort, using the same interface, and that seems
to have worked fine.  This leads me to believe that this qsort
routine may have some problems.  Has anyone else had any
problems of this sort?  (No pun intended)

Jerry Gilliam










Path: ucivax!gateway
From: [e-mail]
Subject: GenApp
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 5 Jul 90 19:17:01 GMT

Has anybody else had trouble with this? I've followed the
instructions on the readme file, but still get some compile errors.
When compiling AboutBox.c, I get an error saying "call of 'PtoCstr'
 does not match prototype".
Anyone else had this happen to them?

Natalio










Path: ucivax!gateway
From: [e-mail] (Bradley A Osborne)
Subject: MacinTalk
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 6 Jul 90 22:03:33 GMT


Hello!

I know that MacinTalk is supposed to be phased out with system 7, but
I am interested in playing around with it.  Does anyone have the interface
libraries/routines for use with THC?

Thanks.











Path: ucivax!gateway
From: [e-mail]
Subject: GenAPP Problem
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 6 Jul 90 22:13:46 GMT

I want to thank everyone for their help. I got 6 responses within
the day! I'm very grateful! I needed to cast the string...
Keep it up! This is very helpfull to those of us starting on Mac
programming!

Natalio










Path: ucivax!gateway
From: [e-mail] (Bradley A Osborne)
Subject: MacinTalk Interfaces
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 8 Jul 90 02:13:15 GMT


Thanks to those of you who helped me find the THC interfaces
for MacinTalk.  I will post the files to the archive soon (which
means as soon as I can UL them without any problems).  Keep up the
good responses on this list!

Thanks.











Path: ucivax!gateway
From: [e-mail] (Rick Zaccone)
Subject: CDialog 1.2
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 8 Jul 90 10:46:13 GMT

I recently got a copy of CDialog 1.1 from the sumex-aim archives.
This is a class library for modeless dialogs.  It doesn't compile with
TC 4.0.2.  The author claims that version 1.2 corrects this problem,
and he has made it available through CompuServe.  Does anyone have a
copy of this that s/he is willing to share?

Perhaps even more important, does anyone have an example of how to use
CDialog?  I found the explanation that came with CDialog to be
lacking.

Rick Zaccone
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Macintalk Interface
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 24
Date: 8 Jul 90 16:16:31 GMT
Phone: [phone]

[Administrative note: From this message on, I will preface archive
 addition messages with ARCHIVE: for easier recognition.  Also, to
 all those out there who want email access to the archive, it should
 be available within the week -- I'm looking at two different
 packages and will decide on one Real Soon Now.]

Date: Sun, 8 Jul 90 09:34:28 -0500
From: Bradley A Osborne <[e-mail]>

This file contains the libraries and header files which are
needed to use the MacinTalk speech driver from Think C.
(MacinTalk is available from rascal.ics.uci.edu in
mac/system-related).  The archive also contains an example program.

BTW#1:  I did not create these files, but downloaded them from
COMPU$$$ERVE.

BTW#2:  Apple has made it abundantly clear that MacinTalk will
NOT be supported in System 7, so don't plan on writing any really
serious applications using this stuff.

Thanks to the folks who responded to my posting requesting these files.

[saved as: /mac/think-c/compiler/macintalk-interface.hqx]










Path: ucivax!gateway
From: [e-mail]
Subject: What's osEvt's value?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 9 Jul 90 19:31:36 GMT


I'm trying to port the user interface code for Disinfectant 2.0
to Think C 4.02.  Things are going pretty well, but there's one
thing I can't find in Inside Mac, SpInside Mac, or the Tech Notes:

What's the actual value of the constant osEvt?  Is it 9, which
is marked as "no longer used?"  Where is it documented?  What
does it mean?










Path: ucivax!gateway
From: [e-mail]
Subject: osEvt - the hidden truth
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 9 Jul 90 20:11:51 GMT


OK, Think C does know about osEvt, suspendResumeMessage, and related
stuff.  Where?  Just read CSwitchboard.c.  osEvt isn't mentioned by
name, but app4Evt is taken as the bearer of suspend/resume messages.
Other useful constants (suspendResumeMessage, ResumeEvtMask) are
locally defined in CSwitchboard.

I've sent a mild reproof to [e-mail], so perhaps
this stupidity will be remedied in a future release.










Path: ucivax!gateway
From: [e-mail] (Paul Davis)
Subject: dialogs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 12 Jul 90 02:11:13 GMT

Is this the THINK C forum?  I got this address from the Internet
a while back...

My query: I am using TC4 for a small application and have gotten
around to wanting to add some configuration dialogs.  These are
modal, and contain only standard dialog items (checkbox, radio
buttons, and std. buttons; maybe someday a popup or two).  My
question is, are people out there using TCL using the standard
dialog manager for dialogs, or creating a TCL CDirector etc.
If standard dialogs, does someone have some neat routines for
a CDialogMgr object to interface to the toolbox manager?  If
using TCL for all button objects etc., what are you overriding
to disable menus clicks, other windows etc.; the CDeskTop?

Quids pro: I have created a GridPanel subclass to CScrollPane
which implements a set of panes such that they behave as a
spreadsheet does when you 'freeze titles', ie. the top pane
scrolls horizontally with the main pane, the left pane scrolls
vertically with the main pane, and the upper left corner just
sits there.  Any interest?

Replies to: [e-mail]

Paul Davis, School of Business, Bond University, Australia










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Think C Marker
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 25
Date: 13 Jul 90 21:05:25 GMT
Phone: [phone]

I am posting the attached for a friend.  It's a neat hack that gives the
Think C (4.0.x) editor a "mark" facility.  It provides a menu of all the
procedures and methods in your src files.  Selecting an item in the menu
causes the editor to jump to the start of that routine.  You can also
define your own place marks.

When you unstuff the file, you will find an installer application.  Run
it, and tell the installer where your copy of TC is (backup first!).
Click on "Help" for full details.

Shareware.  If you like it, write to Symantec and tell them to include
it in the next version of Think C.

I was a beta-tester, but have no other connections with the product.

Sak Wathanasin
Network Analysis Limited

uucp:    ...!ukc!nan!sw
other:    [e-mail]
phone:  [phone]
telex:  9312130355 (SW G)
snail:  178 Wainbody Ave South, Coventry CV3 6BX, UK

[saved as: /mac/think-c/compiler/marker.hqx]










Path: ucivax!gateway
From: [e-mail] ("Charles E. Houpt")
Subject: problem with conditional expressions that return structures
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 15 Jul 90 06:41:14 GMT

The Think C compiler flags an error when you try to make a conditional
expression return a structure. The compiler says its an "illegal operation
on struct/union". Here's an example:

struct point {
    int x;
    int y;
};

struct point ok_max_x(a,b)
struct point a,b;
{
    if (a.x>b.x) return a;
    else return b;
}

struct point error_max_x(a,b)
struct point a,b;
{
/* Think C: Illegal operation on struct/union */
    return (a.x>b.x) ? a : b;
}

The 2nd edition K&R seems to say it should be legal (Appedix A7.16).
And the BSD and Sun compilers accept this code.

Is this a bug in Think C?

Thanks, Chuck Houpt.
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Pointer problems
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.2 PL0]
Newsgroups: fa.think-c
Lines: 39
Date: 16 Jul 90 00:15:16 GMT

OK, I'm baffled. The one reason I liked to program in Pascal was
because I understood pointers when I programmed in Pascal. Now, in C,
I no longer do.

This piece of code gives me the compile time error "pointer required"
in THINK C on the line that says "errCode = ...". What I am trying to
do is pass the address of the fourth byte as the first parameter and
the contents of the third byte as the third parameter.

#define FIRST_STRING_OFFSET    2
#define FULL_NAME_INDEX     1
#define NUM_OF_STRINGS        5
#define STRL_RSRC        'STR#'
#define USER_NAMES_STRL_ID    128

main()
{
Handle NamesList;
StringHandle SomeStrings[NUM_OF_STRINGS];
OSErr errCode;

NamesList = Get1Resource(STRL_RSRC, USER_NAMES_STRL_ID);
errCode = PtrToHand(&(**NamesList)[FIRST_STRING_OFFSET + 1],
                    SomeStrings[FULL_NAME_INDEX],
                    (**NamesList)[FIRST_STRING_OFFSET]);
}

What am I doing wrong, or more to the point, what do I do to make this
work? I am missing something obvious. There is also probably a much
niftier way to do this that I can't figure out, and I would be partial
to getting some hints.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : [e-mail]
BITNET (if no other way) : FREE0285@UIUCVMD










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: archive mail server info
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 20
Date: 16 Jul 90 16:08:57 GMT
Phone: [phone]

OK everyone, I have installed an archive server on ics.uci.edu.  I
was going to write my own and thus be sure of it, but I have other
more important projects pending, so I snagged the source to the
Clarkson archive server.  After tweaking it a bit, I managed to get
it functioning.  So, please give it a try and let me know if you
encounter any problems.  The server accepts various commands, most
of which use a "standard" syntax.  To begin, send a message to:

    [e-mail]

with a Subject: of help.  This will send you a copy of the help file
for using the server.  To get a file from the think-c archive, you
should send a message with a Subject: of (for example):

    send mac/think-c/compiler marker.hqx

If you need it, use it, and once again, please let me know if you
have problems.

Mark










Path: ucivax!gateway
From: [e-mail] (Rick Zaccone)
Subject: CDialog 1.2 (again)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 17 Jul 90 09:14:09 GMT

A couple of weeks ago I sent a message asking if anyone had a copy of
CDialog 1.2.  Several people responded that they too would like to get
a copy.  However, no one actually came through with a copy.  The
author claims that version 1.2 exists.  Is there anyone who can at
least give me a pointer as to where I might find it?  (I've written to
the author, but he doesn't seem to be answering his mail).

Rick Zaccone
[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: cdialog 1.2
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 6
Date: 19 Jul 90 00:51:54 GMT
Phone: [phone]

Rick Zaccone sent in the newest version of the CDialog class,
version 1.2.

Mark

[saved as: mac/think-c/classes/cdialog-12.hqx]










Path: ucivax!gateway
From: [e-mail] (Emlen Dave T)
Subject: bitmap printing questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 55
Date: 20 Jul 90 21:03:48 GMT


I'm writing a quick 'n' dirty program to dump a bitmap to a printer.  Here's
my print code:

>extern  BitMap  my_bitmap;
>static  THPrint hPrint = nil;
>
>CheckPrintHandle()
>{
>    if (hPrint==nil)
>        PrintDefault(hPrint = (TPrint **) NewHandle( sizeof( TPrint )));
>}
>
>
>DoPrint()
>{
>TPPrPort        printPort;
>GrafPtr         savePort;
>TPrStatus       prStatus;
>
>    PrOpen();
>    CheckPrintHandle();
>    if (PrJobDialog(hPrint) != 0)
>        {
>            GetPort(&savePort);
>            printPort = PrOpenDoc(hPrint, 0L, 0L);
>            SetPort(printPort);
>            PrOpenPage(printPort, 0L);
>            PrCtlCall(iPrBitsCtl, &my_bitmap, &(my_bitmap.bounds), lPaintBits);
>            PrClosePage(printPort);
>            PrCloseDoc(printPort);
>            PrPicFile(hPrint, 0L, 0L, 0L, &prStatus);
>            SetPort(savePort);
>        }
>    PrClose();
>}

This prints out on the LaserWriter at 72 dpi (it makes no difference if I
change lPaintBits to lScreenBits).  How do I get the bitmap to be printed
at > 72 dpi (e.g. 300 dpi)?

The reason that I'm writing this is so I can have an easy way to send an
image scanned in at 200 dpi to a DoveFax modem, which looks like a 200 dpi
printer to applications.

This brings me to my second question.  The above code prints fine to a
LaserWriter (aside from being 72 dpi), but when I select the DoveFax modem
in the chooser and try to print, I get a -17 printing error from the
print driver.  I believe -17 means "Driver can't respond to Control call."
What control call could it be referring to?

Thanks in advance.

-Dave Emlen
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: bitmap printing questions
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Newsgroups: fa.think-c
Lines: 75
Date: 23 Jul 90 03:10:20 GMT

Your problem could be The iPrBitsCtl call.  You may have to use
CopyBits to print to your fax modem.

I enclose some code I used to print to my LW II SC at 300 dpi.
The application this came from drew figures with Quickdraw, but The
printing wrapper code came from an app (to which I have since lost The
sources) that printed bitmaps at 300dpi.  The important thing is the
PrGeneral/setRslOp call.  Otherwise, you will print at 72dpi.


do_print()
{
    TPPrPort pr_port;
    int scale, hscale, vscale, save_scale;
    Point origin, maxpt, save_origin;
    int i;
    TPrStatus st_rec;
    TGetRslBlk grsl;
    TSetRslBlk srsl;
    int resl;

    /* Some application specific stuff was here. */

    if ( !printer_is_open )
        do_page_setup();
    if ( !printer_is_open )
        return;        /* if error */

    if ( !PrJobDialog( hPrint ) )
        return;

    /* Set printer to best resolution */
    grsl.iOpCode = getRslDataOp;
    PrGeneral( &grsl );
    resl = 0;
    if ( grsl.iError == noErr )
    {
        for ( i = 0; i < grsl.iRslRecCnt; i++ )
            if ( grsl.rgRslRec[i].iXRsl == grsl.rgRslRec[i].iYRsl &&
                 grsl.rgRslRec[i].iXRsl > resl )
                resl = grsl.rgRslRec[i].iXRsl;
        if ( resl != 0 )
        {
            srsl.iOpCode = setRslOp;
            srsl.hPrint = hPrint;
            srsl.iXRsl = resl;
            srsl.iYRsl = resl;
            PrGeneral( &srsl );
        }
    }

    /* More application specific stuff to determine appropriate
     * scaling to print at this resolution was here.
     */

    pr_port = PrOpenDoc( hPrint, nil, nil );
    if ( PrError() == noErr )
    {
        PrOpenPage( pr_port, nil );
        if ( PrError() == noErr )
        {
            /* Actually print by drawing. */
        }
        PrClosePage( pr_port );
    }
    PrCloseDoc( pr_port );

    if ( (*hPrint)->prJob.bJDocLoop == bSpoolLoop && PrError() == noErr )
        PrPicFile( hPrint, nil, nil, nil, &st_rec );
    if ( PrError() != noErr )
        SysBeep( 2 );
}

=Spencer W. Thomas         EECS Dept, U of Michigan, Ann Arbor, MI 48109
[e-mail]        313-936-2616 (8-6 E[SD]T M-F)










Path: ucivax!gateway
From: [e-mail]
Subject: C++
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 23 Jul 90 20:01:03 GMT

Does anyone know if there is a full C++ (2.x) implementation
planned for a future version of THINK C?  If so, are there also
plans for THINK C to then stay current with AT&T C++ including
parameterized types and error handling?

While error handling is valuable, from a programming productivity
and code-reusability perspective, I am really looking forward to
parameterized types.

Thanks,

Steve Leeke

[e-mail]

[phone]

Computer Science Center
Texas Instruments, Inc.
MS 238
P.O. Box 655474
Dallas, TX 75265











Path: ucivax!gateway
From: [e-mail] (Bradley A Osborne)
Subject: Pyro!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 25 Jul 90 00:38:41 GMT


There has been some interest expressed here in writing Pyro! modules using
Think C.  If someone can convince me that the people at Pyro! (i forget
the name of the company) would not mind my doing so, I will post the
development guide, header files, and sample projects for Think C to the
archive (I must be sure that no Copyright laws would be violated)

BTW:  I have not purchased Pyro!, but my roomate has.











Path: ucivax!gateway
From: [e-mail] (Jerry Frain)
Subject: Re: C++
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at Jul 23, 90 8:01 pm
X-Mailer: ELM [version 2.3 PL5]
Newsgroups: fa.think-c
Lines: 26
Date: 25 Jul 90 13:06:46 GMT

>
> Does anyone know if there is a full C++ (2.x) implementation
> planned for a future version of THINK C?  If so, are there also
> plans for THINK C to then stay current with AT&T C++ including
> parameterized types and error handling?
>
> While error handling is valuable, from a programming productivity
> and code-reusability perspective, I am really looking forward to
> parameterized types.

Wow.  This man reads my mind.

A while back I posted an article to comp.sys.mac.programmer complaining
that the THINK C OOP really doesn't hold a candle to C++.  I find things
like redefining operators a must.

Someone else followed up my article, and pleaded for someone (he hinted
to Rich Siegel, a Symantec staff software developer) to at least hint
at what Symantec had in mind for the future of THINK C.

Rich replied to his article, and let us know that he's not saying anything.

THINK by far is the best C compiler out there for the Mac, but I wish
they would bring it up to a full C++ implementation

  --Jerry